Object-Oriented Modelling of Distributed Multimedia Services

class SSO { ... public: SessionID createSession(ClientID,SessionInfo, SessionPermission); boolean destroySession(ClientID,SessionID); boolean joinSession(ClientID,SessionID); boolean leaveSession(ClientID,SessionID); boolean inviteSession(ClientID,SessionID, ClientID); int howManySessions(SystemID); SessionID getSessionID(SystemID,Order); SessionInfo getSessionInfo(SessionID); SessionPermission getSessionPermission (SessionID); } SSO is similar with NSO. SessionID is a unique value which identi es a session, too. And SessionPermission is set by the creator of the session. It describes which application can join a session or not. 3.3 Multimedia Communication Service Object (MCSO) A variety of multimedia data types and interfaces constitute media classes. It is because they need similar interfaces, which perform in very di erent ways according to characteristics of each multimedia data. If they are not de ned as classes, multimedia application developers must remember all data types and related interfaces. It is likely to make many errors. And the classes make a hierarchy, so duplications of source codes can be reduced using inheritance and overloading. The following is a media class hierarchy and brief de nitions of the classes. 3.3.1 Media Class Hierarchy There are three main classes in the media class hierarchy. The rst class is Media which is a super class. It has common interfaces for not only non-temporal but also temporal multimedia data. The second class is Temporal which has common interfaces for temporal multimedia data. And the last class is AVsync which has interfaces for both video and audio data which should be synchronized into one stream. Figure 2 is a media class hierarchy of our system. 3.3.2 Media Class De nition Hereafter we describe the three main classes. Media Class abstract class Media { ... public: boolean sendData(Source,Destination,Data); MediaData recvData(Source); } Media Text Still Image Graphics Temporal Audio Video Music Animation AVsync Speaker Microphone Camera Monitor Figure 2: Media Class Hierarchy The two interfaces support communications for nontemporal multimedia data. The parameters, Source and Destination are ClientID type. Temporal Class abstract class Temporal:public Media { ... public: boolean setDevice(SourceDevice, DestinationDevice,CompressOpt); boolean startStream(); boolean stopStream(); boolean pauseStream(); boolean resumeStream(); boolean freeDevice(Device); } Temporal class has common interfaces for transmitting temporal multimedia data. setDevice sets source device and destination device which are needed for transmitting. And CompressOpt is the compression technique. After setting source and destination devices, an application can call startStream to start sending multimedia data. Also, it can call stopStream to stop sending and then can free the devices by using freeDevice. In addition, the transmission can pause by using pauseStream and it can resume by using resumeStream. Audio and Video Class abstract class Audio:public Temporal { ; ; ; ; ; ; ; public: boolean storage(Destination); boolean retrieval(Source); boolean edit(EditOpt); boolean effects(EffectsOpt); boolean conversion(ConversionOpt); } abstract class Video:public Temporal { ; ; ; ; ; ; ; ; ; public: boolean storage(Destination); boolean retrieval(Source); boolean edit(EditOpt); boolean effects(EffectsOpt); boolean conversion(ConversionOpt); } In the above classes, there are some data and interfaces for audio and video data. But the classes inherit data and interfaces from Temporal, so Audio and Video classes can use data and interface of Temporal class or rede ne them. AVsync Class abstract class AVsync:public Audio,Video { ... public: boolean setDevice(SourceVideoDevice, DestinationVideoDevice,SourceAudioDevice, DestinationAudioDevice,VideoCompressOpt, AudioCompressOpt); boolean startStream(); boolean stopStream(); boolean pauseStream(); boolean resumeStream(); boolean freeDevice(Device); } AVsync class inherits interfaces from both Video and Audio classes. It rede nes some interfaces to synchronize video and audio data. But the processing for transmitting synchronized multimedia data is the same as that of Temporal class. 3.4 Storage/Retrieval Service Object (SRSO) SRSO is de ned as follows. abstract class SRSO { ... public: boolean storeMultimedia(Location, ObjectReference); ObjectReference retrieveMultimedia(Location); } Location represents the location where multimedia data is stored in or retrieved from. And ObjectReference is a reference to multimedia data object which is stored or retrieved. 3.5 Management Service Object (MSO) MSO is de ned as follows. abstract class MSO { ; ... public: SystemStatus getStatus(SystemID); SystemStatistics getStatistics(SystemID, Statistics); SystemConfiguration getConfiguration (SystemID); ObjectBackup returnBackup(SystemID, ServiceObject); boolean informMonitoringInfo(SystemID); boolean informMonitoringInfo(ClientID); } Data for each object in the system is backed up as in MSO. Statistics is throughput or CPU utilization of each object. returnBackup is used by an object which restarts after a temporary failure. Each object in the system must inherit data and interfaces from MIO (Management Interface Object) to have common management interfaces, which are used by MSO. MIO is de ned as follows but can be rede ned or make up for some objects. abstract class MIO { ; ; ; public: ObjectStatus getStatus(); ObjectStatistics getStatistics(Statistics); boolean backup(); boolean stopService(ClientID); boolean resumeService(ClientID); boolean setPermission(Permission); boolean redirectService(ClientID,SystemID); } represents whether the status of each object is busy or idle and is the total time which an object has taken to provide requested services so far. So the throughput is calculated with and . getStatus and getStatistics is used to get monitoring information from each object, backup to get backup data stopService, resumeService, setPermission and redirectService to recon gure service scopes. 4 Prototype Implementation Based on the modeling of distributed multimedia services explained in the previous section, we are now developing a multimedia system called MAESTRO using IONA Orbix 2.0 [9] which is one of CORBA (Common Object Request Broker Architecture) [12] platforms. The architecture of MAESTRO is shown in Figure 3. The current version of MAESTRO is structured as a set ofclass Video:public Temporal { ; ; ; ; ; ; ; ; ; public: boolean storage(Destination); boolean retrieval(Source); boolean edit(EditOpt); boolean effects(EffectsOpt); boolean conversion(ConversionOpt); } In the above classes, there are some data and interfaces for audio and video data. But the classes inherit data and interfaces from Temporal, so Audio and Video classes can use data and interface of Temporal class or rede ne them. AVsync Class abstract class AVsync:public Audio,Video { ... public: boolean setDevice(SourceVideoDevice, DestinationVideoDevice,SourceAudioDevice, DestinationAudioDevice,VideoCompressOpt, AudioCompressOpt); boolean startStream(); boolean stopStream(); boolean pauseStream(); boolean resumeStream(); boolean freeDevice(Device); } AVsync class inherits interfaces from both Video and Audio classes. It rede nes some interfaces to synchronize video and audio data. But the processing for transmitting synchronized multimedia data is the same as that of Temporal class. 3.4 Storage/Retrieval Service Object (SRSO) SRSO is de ned as follows. abstract class SRSO { ... public: boolean storeMultimedia(Location, ObjectReference); ObjectReference retrieveMultimedia(Location); } Location represents the location where multimedia data is stored in or retrieved from. And ObjectReference is a reference to multimedia data object which is stored or retrieved. 3.5 Management Service Object (MSO) MSO is de ned as follows. abstract class MSO { ; ... public: SystemStatus getStatus(SystemID); SystemStatistics getStatistics(SystemID, Statistics); SystemConfiguration getConfiguration (SystemID); ObjectBackup returnBackup(SystemID, ServiceObject); boolean informMonitoringInfo(SystemID); boolean informMonitoringInfo(ClientID); } Data for each object in the system is backed up as in MSO. Statistics is throughput or CPU utilization of each object. returnBackup is used by an object which restarts after a temporary failure. Each object in the system must inherit data and interfaces from MIO (Management Interface Object) to have common management interfaces, which are used by MSO. MIO is de ned as follows but can be rede ned or make up for some objects. abstract class MIO { ; ; ; public: ObjectStatus getStatus(); ObjectStatistics getStatistics(Statistics); boolean backup(); boolean stopService(ClientID); boolean resumeService(ClientID); boolean setPermission(Permission); boolean redirectService(ClientID,SystemID); } represents whether the status of each object is busy or idle and is the total time which an object has taken to provide requested services so far. So the throughput is calculated with and . getStatus and getStatistics is used to get monitoring information from each object, backup to get backup data stopService, resumeService, setPermission and redirectService to recon gure service scopes. 4 Prototype Implementation Based on the modeling of distributed multimedia services explained in the previous section, we are now developing a multimedia system called MAESTRO using IONA Orbix 2.0 [9] which is one of CORBA (Common Object Request Broker Architecture) [12] platforms. The architecture of MAESTRO is shown in Figure 3. The current version of MAESTRO is structured as a set of distributed objects that work cooperatively to realize the API. Distributed DBMS Audio Video SRSO NSO SSO MCSO MSO Client Client Client Distributed Storages APIs Communication with other serversMultimedia ServerText GraphicsClient Figure 3: Implementation Architecture of MAESTROThe architecture includes two types of objects: perma-nent objects and transient objects. Permanent objects suchas NSO, SSO, MCSO, SRSO, MSO are a part of the serverand instantiated when the server is started. Transient ob-jects which is instantiated using media class (e.g., Audio,Video, Music, Animation, etc.) are a part of a client andinstantiated by a client. The reason why transient objectsare needed is that these objects control local devices whichare used by a client or represent multimedia data which iscreated by a client. And permanent objects exist as longas the server is available to clients and transient objectsexist for a limited amount of time by a client.Note that all objects including permanent and transientobjects are manipulated by API routines and some APIroutines which manipulate transient objects do not have tocommunicate with the server but some other API routines,which manipulate permanent objects, communicate withthe server.Servers in MAESTRO provide communication mecha-nism to clients. They cooperate with each other so thata client which is using one server can communicate with aclient which is using another server.For a practical implementation, we adopted interna-tional standards such as H.261 [10], H.221, G.711, G.722and G.728. These are used for video and audio compres-sion and multiplexing. In addition, we intend to follow theinternational standards on multimedia, which are being de-veloped by organizations such as ITU-T, ISO, DAVIC [3]and so on.5 ConclusionWe discussed the motivation behind our work on themodeling of distributed multimedia services and the devel-opment of a distributed multimedia system. We de nedservices which are needed in the system and proposed amodel for the services using the object-oriented methodol-ogy.We developed a rst prototype of MAESTRO whichincludes NSO, SSO and some parts of MCSO based onthe above modeling using IONA Orbix 2.0 which is one ofCORBA platforms. Now we are developing a second pro-totype which includes improved MSCO, SRSO, MSO andMIO. And we are also developing a video conferencing toolusing the APIs provided by MAESTRO.Finally, we will feed back the development experienceto the modeling process, so MAESTRO will be much im-proved.References[1] Barry K. Aldred. IBM Lakes Architecture: Introduc-tion and Programmers' Guide. IBM UK LaboratoriesLtd., 1993. URL http://www.hursley.ibm.com/~p2p/.[2] Interactive Multimedia Association. IMA Recom-mended Practice Draft, September 1994. URLhttp://www.ima.org:80/forums/imf/mss/.[3] Digital Audio-Vidio Council. Davic 1.0 speci cationpart 1 part 10. Technical report, September 1995.[4] P. Dubois. Detailed Speci cation of the BETEUS ap-plication platform. BETEUS consortium, November1994. URL http://www.tik.ee.ethz.ch/~beteus/.[5] Eelectronics and Telecommunications Research Insti-tute (ETRI). MuX Tutorial, 1995.[6] M. Arango et al. The touring machine system. Com-munications of the ACM, 36(1):68{77, January 1993.[7] H. Lut yya G. S. Perrow, J. W. Hong and M. A.Bauer. The Abstraction and Modeling of ManagementAgents. Proc. of the Fourth International Symposiumon Integrated Network Management, pages 466{478,May, 1995, Santa Barbara CA.[8] J. Won-Ki Hong. Distributed systems managementtechnology. KISS Review, 14(1):51{61, January 1996.[9] IONA. Orbix 2. IONA Technologies Ltd., November1995. Release 2.0.[10] ITU-T. Video Codec For Audiovisual Services at p 64kbi, March 1994. ITU-T Recommendation H.261.[11] J. Hong J. Rolia T. Teorey M. Bauer, P. Finnigan andG. Winters. Reference architecture for distributed sys-tems management. IBM Systems Journal, 33(3):426{444, September 1994.[12] OMG. The Common Object Request Broker : Ar-chitecture and Speci cation Revision 2.0. OMG, July1995. OMG TC Document.[13] David Kenney Ward Rosenberry and Gerry Fisher.Understanding DCE. O'Reilly & Associates, Inc.,1992.